Performance Management, PM, functions in a mobile telecommunications system are used for monitoring, trouble shooting and optimisation of the mobile telecommunications system. The PM functions are based on events and counters generated by the several system elements of the mobile telecommunications system, among which radio access units or Base Stations, BS, radio network controllers and other system nodes and servers.
Events are used to monitor and investigate the elementary system operation. Relevant information of the operation of the system can be obtained from a long time observation of the events data.
Counters are used to obtain aggregate or statistical information of the system. Counters are implemented in the various system elements but can also be created from events and event parameters. There is a continuously increasing number of predefined counters that are recorded in the system elements.
Examples for the recording of events are the General Performance Event handler, GPEH, and User Equipment Traffic Recording, UETR, functions of system elements. An example for collecting statistical counters is the STATS function of system elements in, for example, third generation, 3G, and Long Term Evolution, LTE, mobile telecommunications systems. Note that events data and counter values generated by a plurality of system elements may be collected by a common server or gateway instead of by the system elements themselves.
The events data and counter values may be forwarded directly, in real-time, to a management server or gateway, which is part of an Operating Support System, OSS, by using a streaming application, for example. However, the events and counters may also be collected in files for a set period of time, called the Result Output Period, ROP, before forwarding thereof to the OSS. ROP files are retrieved periodically from the system elements and processed in the OSS. Both, real-time events data and counter values as well as ROP files may be available for processing by the OSS.
An OSS implements several types of PM functions such as traffic monitoring, trouble-shooting, radio and transport network optimisation. From the processed events and counters Key Performance Indicators, KPIs, can be driven that are used for monitoring, trouble shooting and planning purposes. KPIs are used for high level monitoring and business planning functions. These functions are not necessarily part of the OSS.
An OSS may also include applications for user defined counters to be created from events or event combinations, which provides an extended observation possibility for telecommunications systems. Besides the above, the events data and counter values may be used by other applications as well.
LTE networks, for example, implement a lot of auto-configuration functions and use default configurations which provide fast installation and stable operation in the initial phase of a systems setup. However, monitoring of the overall operation of the large number of system elements requires a centralized management system. Exceptional conditions and operations should be observed by a performance monitoring OSS. Performance monitoring tools and functions are also needed in order to optimise the operation of LTE.
A problem of LTE performance monitoring is the plural numbers of nodes and cells, i.e. femto cells, that have to be monitored. These nodes, also called LTE eNodeB, generate larger numbers of events and counters that have to be processed compared to previous mobile Radio Access Network, RAN, systems, such as GSM RAN, for example.
Scalability issues occur if the OSS has to communicate and collect events data and counter values directly for large numbers of system elements, such as the LTE eNodeBs. In particular in the absence of (intermediate) control nodes, which are also used for collecting and pre-processing PM data from the system elements in GSM and WCDMA RAN systems.
Another problem with newly deployed systems and system technology is the lack of reference data for the different parameters, to derive KPIs, for example. Current PM monitoring functions need a lot of prior knowledge of the system, or decent operational experience, which means more expensive implementations and increased operating expenses. This is in particular a problem for small system operators which are not able to invest in the implementation of such tools and do not have large experienced staff for evaluation and system operation.